Nowadays, internet access is both popular and easy to obtain. Anyone with a personal computer, modem and telephone line may sign up with an internet access provider for access to the internet. The magnitude and availability of information on the internet continues to increase the popularity of the internet. In turn, the popularity of the internet has led to tremendous growth in the number of internet users, as well as an increase in the amount of time each user spends on the internet.
For many users of the internet, an increase in the volume of traffic on networks connected to the internet translates into slower transmission of information. A high volume of traffic may slow the rate of speed associated with transmitting information over the networks thereby aggravating or frustrating internet users. Additionally, many internet users pay for internet service based on hourly network usage. Therefore, the slow transmission of information translates into the user getting less for his or her money.
For network service providers, there are several drawbacks associated with the increasing volume of network traffic. Traffic on the network may cause a delay in receiving a request from a subscriber, as well as a delay in a service provider's ability to respond to the subscriber request. Moreover, network service providers realize that when internet service is too slow, subscribers may become frustrated and decide to cancel their subscription.
Service providers generally attempt to fulfill the requests of subscribers as fast as possible. Network service providers are typically able to provide requested information more quickly when the requested information is stored within the network. Thus, network service providers often choose to store data within the network that may be frequently requested by service subscribers.
The ability to rapidly provide subscribers with requested information gives the network service providers an incentive to store greater quantities of information within the network. However, storing greater quantities of information requires additional storage space, which in turn generally increases the expenses of the service provider. Thus, the increasing volume of network traffic forces service providers to strike a balance between acceptable transmission delays, available data storage space and the cost of utilizing additional storage space.
Network service providers have developed numerous approaches in an attempt to reduce transmission delays. In one approach, a central office receives a request for information from a user. The central office simply acts as a middle-man between the user and the network core. Thus, the central office forwards the request to the network core. Once received by the network core, the request may be fulfilled by the information contained within the network core. However, if the network core cannot fulfill the request, the network core may request the information from another element, such as another network or a larger information store.
This approach is prone to the “straight-to-core” drawback. As it's name suggests, the straight-to-core drawback occurs when a central office routes a request directly to the network's core. By routing all incoming requests directly to the network core, the network core may become overwhelmed by the large volume of requests. Moreover, the transmission routes between the central office and the network core may become overcrowded. Thus, requests that are subject to the straight-to-core drawback may be delayed at several points during transmission. For example, the request may take longer to arrive at the network core due to traffic on the transmission route to the network core. The request also may be delayed once it arrives at the network core, if the core has a backlog of requests to fulfill. Additionally, once fulfilled, the request may be delayed due to traffic in the route back to the central office.
In another approach, the central office forwards a request to a client, referred to as a “host,” attached to the rest of the clients within the network. Once the host has received the request, the host may provide the request to any client within the network. Typically, the host will provide the request to the client with the least traffic. Alternatively, the host may provide the request to a specific client based on the subject matter of the particular request.
This approach is susceptible to excessive network traffic at the host, referred to as the “host-bottleneck” drawback. The host-bottleneck drawback occurs when the host receives requests at a faster rate than the rate at which the host satisfies the requests. Thus, the requests begin to create a backlog while waiting to be processed by the host. The host-bottleneck drawback is even more problematic if the fulfilled requests returning from the clients are also required to pass through the host.
Another drawback of this approach is the “offline-host” drawback. The offline-host drawback occurs when the host is offline or not functioning properly. Thus, any approach that utilizes a host to receive messages from the users may suffer to some extent from the offline-host drawback.
In a variation of the host approach, an initial request from a user is forwarded to a host. However, the host does not receive any of the subsequent requests from that particular user. Instead, based on the initial request, the host selects a client to receive the subsequent requests from that particular user.
This variation of the previous approach reduces the host-bottleneck drawback, however, this approach creates other drawbacks. One drawback created by this approach is the “atypical request” drawback. The atypical request drawback occurs when a user's initial request is substantially different from the majority of the user's subsequent requests. The atypical request drawback is most noticeable and problematic when a user's subsequent request is much larger than the user's initial request. Thus, the client may become overloaded with requests because the traffic from a particular user is heavier than anticipated by the host.
This approach may also suffer from the offline-host drawback. The network will not be capable of receiving a request and selecting an appropriate client whenever the host is offline. However, contrary to the previous approach, in this approach the off-line host drawback will only interfere with the processing of initial requests from new users.
In yet another approach, the central office may be instructed to provide a request to a particular client based on the subject matter of the request. Alternatively, the central office may automatically reroute a request from one particular client to another client during predetermined time periods. For example, a network may include a client that is typically busy between 11:00 AM and 1:00 PM. The central office may be instructed to reroute a portion of the requests initially directed to the busy client to a client that is typically not busy between the hours of 11:00 AM and 1:00 PM.
One drawback of this approach, referred to as the “rigid instruction” drawback, is that the network does not adjust when the circumstances within the network are temporarily altered. Thus, the central office will rigidly follow the instructions even though it may be more efficient to do otherwise. In the example above, there will be instances when the client that is typically busy between 11:00 AM and 1:00 PM is not busy during those hours. However, the central office will rigidly follow the provided instructions and continue to reroute the requests away from that particular client.
One drawback that may occur in several of the current approaches is termed the “busier neighbor” drawback. The busier neighbor drawback may occur in any approach where an overloaded client is programmed or directed to reduce its load by forwarding a request to a neighboring client. A neighboring client is typically determined by geographic proximity. For example, the neighboring client may be within the same room or office building. As another example, the closest neighboring client may be in a different city.
Frequently, the request from an overloaded client is forwarded without considering the workload of the neighboring client. Hence, there are occasions when an overloaded client forwards a request to an equally busy or busier neighboring client. Forwarding the request to a busier neighbor client further exasperates the problems related to traffic within the network.
In sum, there is a need to fulfill requests for information from a network while reducing the load on the network core and the traffic on routes within the network. There is a further need to satisfy requests from the network in the shortest period of time.